Hello Svelte Team,

I send you this PR to make handleFetch a shared hook that can be used on both client and server side.

Motivation

I'm working a hybrid client/server administration portal where authentication is done using OAuth/OIDC + JWT tokens. I'm trying to create a secure and performant authentication process and I noticed that we could create something very powerful with SvelteKit by improving some features.

Indeed, a good practice when working on a SSR environment is:

1. Make all requests to auth server on the server side
2. Transmit access token and refresh token to client
3. Keep only the refresh token on a cookie (not the access token)
4. When a new request is done using the server, refresh the token and transmit the new refresh token to the client.

However, on a very hybrid scenarios where requests are done sometimes on the client, sometimes on the server, it multiplies the numbers of refresh token requests and create a bottleneck on the auth server.

So a good improvement would be to constantly pass the access token from the client to the server to allow reusing during the session. I noticed that we can take control of fetch requests on the server side but not on the client side.

Other use cases

I see some scenarios where controling the client-side fetch would be useful:

• Automatically exchange token information (like explained above)
• Automatically exchange headers with server-side load and action functions
• Automatically includes credentials to requests to API
• Logging and monitoring fetch requests

Implementation

This PR replicates the behavior of the server-side handleFetch hook with one difference: the hook does not have access to event.

Notes

I wanted to include a test similar to the server-side handleFetch. However I did not find any tests for server-side handleFetch.
I'm open to any idea to create tests for both hooks.

Edit : I finally found my way and included some tests, do not hesitate to review them!

Please don't delete this checklist! Before submitting the PR, please make sure you do the following:

• It's really useful if your PR references an issue where it is discussed ahead of time. In many cases, features are absent for a reason. For large changes, please create an RFC: https://github.com/sveltejs/rfcs
• This message body should clearly illustrate what problems it solves.
• Ideally, include a test that fails without this PR but passes with it.

Tests

• Run the tests with pnpm test and lint the project with pnpm lint and pnpm check

Changesets

• If your PR makes a change that should be noted in one or more packages' changelogs, generate a changeset by running pnpm changeset and following the prompts. Changesets that add features should be minor and those that fix bugs should be patch. Please prefix changeset messages with feat:, fix:, or chore:.

Edits

• Please ensure that 'Allow edits from maintainers' is checked. PRs without this option may be closed.